home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1992 June: ROMin Holiday / ADC Developer CD (1992-06) (''ROMin Holiday'')_iso / Developer Connection - 06-1992.iso / Development Platforms / Apple II / Essentials / Technical.Notes / GSOS / TN.GSOS.003 < prev    next >
Encoding:
Text File  |  1988-12-22  |  4.9 KB  |  100 lines  |  [TEXT/pdos]
  1. Apple II
  2. Technical Notes
  3. _____________________________________________________________________________
  4.                                                   Developer Technical Support
  5.  
  6.  
  7. GS/OS
  8. #3:    Pointers on Caching
  9.  
  10. Written by:    Matt Deatherage                                  November 1988
  11.  
  12. This Technical Note discusses effective use of the GS/OS cache.
  13. _____________________________________________________________________________
  14.  
  15.  
  16. Introduction
  17.  
  18. GS/OS is the first Apple II operating system to offer a sophisticated caching 
  19. mechanism.  However, using the cache and using it wisely are two different 
  20. things.  This Note presents some concepts which should lead to higher 
  21. performance for your application if it uses the cache.
  22.  
  23.  
  24. What's Cached Automatically?
  25.  
  26. All blocks on a GS/OS readable disk could be classified into one of two 
  27. categories.  "Application blocks" are all blocks on the disk contained in any 
  28. file (except a directory file), while "system blocks" are other blocks on the 
  29. disk.  System blocks belong to the file system and include directory blocks, 
  30. bitmap blocks, and other housekeeping blocks specific to the file system.
  31.  
  32. GS/OS always maintains at least a 16K cache, even if the user has set the disk 
  33. cache size to 0K with the Disk Cache new desk accessory.  When the system 
  34. (usually an FST) goes to read a system block, the block is identified as a 
  35. candidate for caching and is cached if possible.  Applications define blocks 
  36. as candidates for caching by using the cachePriority field of many class 1 
  37. GS/OS calls.  Note that class 0 calls do not have this field, thus 
  38. applications using exclusively class 0 calls will not be able to cache any 
  39. application blocks.
  40.  
  41. Although this difference may seem like a limitation, it in fact improves 
  42. performance.  On the Macintosh, most applications that work with files (like 
  43. database managers) leave the file with which they are working open while they 
  44. need it; the file is only closed when the window containing it is closed.  
  45. Apple II programs historically are quite different--they usually read an 
  46. entire file at the beginning, modify it in memory, and write it when the save 
  47. function is selected.  A moment's thought will show that if GS/OS arbitrarily 
  48. cached most or all application blocks, system blocks that would be used again 
  49. (such as directory blocks) will be kicked out to make room for them.  We will 
  50. see that this is probably a bad thing to do.
  51.  
  52.  
  53. How to Cache Effectively
  54.  
  55. The first tendency of many programmers is to attempt to completely cache any 
  56. given file, but this usually leads to a degradation in performance, not an 
  57. improvement.  In small caches such strategies can slow the system to a crawl, 
  58. and large caches offer no significant improvement.  Remember that until the 
  59. cache memory is needed, it is available to the system.  The cache size for 
  60. GS/OS as set by the user is the maximum to be allotted, not the minimum.
  61.  
  62. Suppose you are attempting to cache a 40K file (80 512-byte blocks).  If the 
  63. cache is set to less than 40K, the entire cache will be written through, 
  64. kicking out all system blocks currently cached.  A cache of this size slows 
  65. system performance for little gain, since the entire file could not be cached 
  66. anyway.  Even if the cache is large enough to hold the entire file, you are 
  67. needlessly taking twice the amount of memory with the same file (by reading it 
  68. into memory you have obtained from the Memory Manager and by asking GS/OS to 
  69. keep a copy in the cache).
  70.  
  71. It is evident that the system makes the best use of the cache automatically, 
  72. freeing your application from the duty of caching system blocks, but there are 
  73. certain instances where caching application data can improve system 
  74. performance.
  75.  
  76. An application which does not limit document size to available memory will 
  77. often only keep a portion of the document in memory at any given time.  
  78. Suppose that the beginning of such an application's document file contains a 
  79. header which to various parts of the document file.  (These parts could be 
  80. chapters for a word processor, report formats for a database manager, or 
  81. individual pictures for an animation program.)  This document header is 
  82. probably not very long, but the application will likely need to read it quite 
  83. often to quickly access various portions of the document file.
  84.  
  85. This header is a prime candidate for caching since it is a part of the file 
  86. which will definitely be read many times during the life of the application.  
  87. Contrast this with arbitrarily caching the entire file, which needlessly 
  88. wastes both cache space and available memory to keep a duplicate copy of 
  89. something that may or may not be read from disk again.
  90.  
  91. Although caching provides enormous benefits to GS/OS, indiscriminate use of 
  92. the cache will waste memory and degrade overall system performance.  Be 
  93. prudent and limit your use of the cache to those portions of your document 
  94. files which will be read from disk many times.
  95.  
  96.  
  97. Further Reference
  98. o    GS/OS Reference, Volume 1
  99.  
  100.